1. Technical Field
This invention relates to performance monitoring within a microprocessor, and more particularly to monitoring changes in measured performance parameters. Still more particularly, the present invention relates to a hardware mechanism that measures a rate of change in measured performance events.
2. Description of the Related Art
A benchmark is a test of computer hardware and/or software that evaluates the performance of the computer. Performance signals (measurements) are received, and then compared with baseline figures. For example, if a computer's system bus is designed to have a bandwidth of 20 MB/second, the actual maximum traffic on the system bus is measured and compared to the “benchmark” of 20 MB/second. If the system bus does not perform at the specification level, then steps are taken to determine why not.
Performance signals reflecting the activity of a tested component in the computer system are sent to a Performance Monitor Unit (PMU), which is typically part of a microprocessor being tested. The PMU contains one or more hardware Performance Monitor Counters (PMCs) that accumulate the performance signals. Besides monitoring bus speed as described above, the PMU may monitor and the PMCs may count processor cycles, instructions completed, delay cycles executing a load from memory, Input/Output (I/O) bandwidth, and any other hardware performance features of the microprocessor.
PMU/PMCs can be directly accessed using hardware probes. However, since these hardware probes are very expensive, the contents of the PMU/PMCs are usually accessed via a software interface, such as IBM's Performance Monitor Application Programming Interface (PMAPI), which is a library of APIs that provide access to PMU/PMCs in the microprocessor. A crucial problem with such software interfaces is that, by their software nature, they are not as fast as hardware probes. That is, the software interface might have to take a performance signal off a bus, load the signal into a register, perform a comparison arithmetic function, output the comparison results, etc. Such steps take many clock cycles, after which a transient error may have passed and thus is unavailable for evaluation. Adding additional software layers to attempt to capture the intermittent glitches and/or drops in performance are likely not to be possible without distorting the hardware's original behavior as well as the glitches themselves.
It is often useful to determine if a change in performance signal frequency occurs. For example, when measuring the bandwidth of the system bus described above, consider a situation in which the bandwidth experiences an intermittent drop. Polling software could be written to poll the appropriate PMC at pre-determined periods via an API, and to issue an alert when the intermittent drop is detected. However, this additional layer of polling software would likely affect the benchmark flow, since execution of the polling software would require the use of additional resources of the computer system. Furthermore, it may not be possible to poll the PMC frequently enough to achieve the required granularity needed to capture such transient events.
Therefore, there is a need for a method and system for detecting a change in hardware performance without using additional software. Preferably, the system would include means for generating an action signal responsive to the detected change in hardware performance.